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SYSTEME DE PAIEMENT POUR L 1 UTILISATION DE LOGICIELS 

DESCRIPTION 

Domaine -technique 

5 La presente invention a pour objet un systeme 

de paiement pour 1 1 utilisation de logiciels. Ces 
logiciels peuvent etre de nature quelconque et par 
exemple etre des logiciels enregistres sur un support 
comme les CD-ROM (Compact Disc-Read Only Memory) ou les 
10 DVD-ROM (Digital Versatile Disc-Read Only Memory) ou 
les logiciels telecharges. 

lis peuvent concerner aussi bien des calculs 
scientif iques que des jeux, des techniques assistees 
par ordinateur, du traitement de texte, etc. . 

15 

Etat de la -technique antexrieure 

Le mode actuel de diffusion des logiciels est 
principalement le CD-ROM, et sera tres bientot le 
DVD-ROM. Pour les editeurs de logiciel se pose de fagon 

20 de plus en plus aigue le probleme de la copie 
frauduleuse de ces logiciels. Si, pendant un temps, le 
format du CD-ROM a empeche la recopie sur un support 
vierge, actuellement , les disques inscriptibles et les 
graveurs de CD sont devenus accessibles au niveau du 

25 grand public. Le meme phenomene ne tardera sans doute 
pas a advenir dans le cas de la technologie DVD. 

Un autre mode possible de diffusion des 
logiciels, quoique moins usite pour des raisons de 
performances, est le telechargement . II n'est pas 

30 approprie aux jeux ayant besoin de tres nombreuses 
images, ou scenes en trois dimensions. En revanche, il 
peut se justifier dans d'autres cas. De nombreux 
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logiciels (compilateurs, editeurs . . . ) entrent dans 
cette categorie. Ces logiciels sont en general 
gratuits, car, du fait de leur volume faible qui les 
rend telechargeables , ils seraient tres faciles a 
5 copier d 1 un ordinateur a un autre. 

Par ailleurs, il est clair que le prix d'achat 
eleve d'un logiciel est souvent dissuasif pour les 
utilisateurs . Le cout du support CD-ROM et de sa 
gravure intervient pour tres peu dans ce prix. Le prix 

10 d 1 achat eleve des CD/DVD-ROM actuels correspond avant 
tout a la remuneration de I'editeur et des 
distributeurs des jeux. 

Ces observations donnent a penser qu'il existe 
un besoin pour le paiement a I'acte, ou a la duree ou a 

15 la seance de logiciels sur support CD/DVD-ROM, ou des 
logiciels telecharges. Ainsi, les editeurs se 
remunereront sur une base de clients beaucoup plus 
importante, en fonction de 1 1 utilisation que le client 
fait de ce logiciel. Globalement , un tel procede 

20 devrait plutot developper le chiffre d'affaires de la 
profession. De plus, la copie de support ne presentera 
plus d'interet, puisque de toute fagon, il sera 
necessaire de payer pour 1 1 utilisation de ce logiciel. 

Or, il n ! y a pas, a l'heure actuelle de moyens 

25 fiables et surs pour assurer un paiement pour 
1 1 utilisation de logiciels. La presente invention a 
justement pour but de remedier a cette carence . 

Expose de 1 1 invention 

30 Un systeme de paiement pour 1 1 utilisation de 

logiciel doit pouvoir remplir au moins trois 
f onctions : 
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o controler 1 1 utilisation du logiciel, chaque fois que 
le logiciel est lance, ou bien periodiquement, ou 
bien lorsqu'un evenement particulier se produit dans 
le logiciel (par exemple un changement de "monde" 
5 dans un jeu, un passage au deuxieme acte d'une piece 

de theatre ou de film. . . ) ; alors, le logiciel doit 
demander qu'un paiement soit effectue ; 
o enregistrer les utilisations, pour faire payer 
1 1 utilisateur : si 1 1 utilisateur accepte la demande 

10 de paiement, il faut enregistrer cette demande d'une 

fagon securisee, pour pouvoir le faire payer 
ulterieurement ; la securisation doit interdire a 
1 1 utilisateur d'ef facer ses dettes, et le paiement 
differe doit permettre d'agreger des petits montants, 

15 pour pouvoir presenter a 1 1 utilisateur une note 

globale, periodiquement (une . fois par mois, par 
exemple), pour des raisons pratiques mais aussi du 
fait des couts de recouvrement de ces petits 
montants ; 

20 o reverser periodiquement a I'editeur du logiciel le 
montant du. 

Ces fonctions doivent etre remplies compte 
tenu de certaines contraintes : 

o les CD-ROM peuvent etre etrangers : un systeme de 
25 paiement de logiciel doit done comporter une 

dimension trans-f rontiere, done des mecanismes 
susceptibles d ! etre deployes internationalement , et 
une reconnaissance internat ionale dans des comites de 
standardisation ; 
30 *o 1' interface entre logiciel et les moyens de paiement 
doit etre standardisee de fagon a ce qu'un 
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developpeur de logiciel n ! ait pas a programmer 
lui-meme la logique de paiement correspondant a 
l'emploi de ce logiciel ; 

• le systeme qui enregistre les utilisations doit etre 
capable de declencher des paiements internationaux 
pour remunerer les editeurs de logiciels dans 
n'importe quel pays du monde ; 

• l'agregation pour les paiements des utilisateurs et 
les reversements aux editeurs de logiciels doit etre 
possible : comme indique plus haut, ceci correspond a 
un objectif de simplicity, mais aussi a un souci de 
reduction des couts bancaires ; notamment, dans le 
cas de transactions vers l'etranger, il serait 
inef ficace (voire nefaste) , sur le plan des couts, de 
faire trop d 1 operations de virements de petits 
montants. 

La presente invention repond a toutes ces 
exigences en tenant compte de toutes ces contraintes. A 
cette fin, le systeme de 1' invention comprend un module 
de paiement et des moyens de traitement de messages et 
de paiement. Par ailleurs, le logiciel dont on veut 
controler 1 1 utilisation comprend une interface 
logicielle. Les fonctions de ces moyens sont les 
suivantes : 

• 1' interface logicielle est apte a constituer un 
premier message qui est un message d 1 off re 
d ' utilisation du logiciel, ce premier message 
contenant, notamment, l'identite de l'editeur du 
logiciel, les parametres de 1' off re, la signature 
numerique par l'editeur d'au moins une partie de 
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1* off re, ce premier message etant adresse au module 
de paiement ; 

le module de paiement est apte a recevoir ce premier 
message, a l'afficher, a recevoir en retour 
1 1 acceptation eventuelle de 1 1 utilisateur du 
logiciel, et, en cas d 1 acceptation, a constituer un 
deuxieme message de demande de paiement contenant 
notamment 1' identite de 1 1 utilisateur et celle de 
I'editeur, ainsi qu'une preuve que 1 1 utilisateur 
accepte l f offre, ce module etant apte a adresser ce 
deuxieme message aux moyens de traitement ; 
les moyens de traitement de messages et de paiement 
sont aptes a recevoir le deuxieme message, a 
controler la preuve qu'il contient, a enregistrer la 
demande de paiement avec au moins 1 1 identite de 
1 ■ utilisateur et 1' identite de I'editeur du logiciel, 
le montant a payer, et a crediter I'editeur dudit 
montant, ces moyens etant aptes en outre a constituer 
un troisieme message, qui est un message 
d 1 acquittement , ce troisieme message comprenant, 
notamment, 1' identite des moyens de traitement et une 
signature numerique de 1' off re, ce troisieme message 
etant adresse au module de paiement ; 

le module de paiement est en outre apte a 
retransmettre ce troisieme message a l 1 interface 
logicielle ; 

l'interf ace logicielle est en outre apte a verifier 
la signature des moyens de traitement par rapport aux 
parametres de 1' off re contenue dans le premier 
message et, en cas de concordance, a autoriser 
1 1 utilisation du logiciel. 
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Dans une premiere variante, les moyens de 
traitement de messages et de paiement sont constitues 
par un serveur de paiement distant relie au module de 
paiement par un reseau de telecommunications , ce 
5 serveur recevant et traitant le deuxieme message, 
constituant et emettant le troisieme message. Ce 
serveur de paiement agrege les credits elementaires 
pour, periodiquement , reverser aux editeurs le montant 
qui leur est du. 

10 Dans une seconde variante les moyens de 

traitement de messages et de paiement comprennent des 
moyens securises contenant au moins l'identite de 
1 f utilisateur, ces moyens etant de plus aptes a 
recevoir le deuxieme message, a controler la preuve 

15 qu f il contient, a enregistrer la demande de paiement et 
a constituer le troisieme message d 1 acquittement , et 
comprennent en outre un serveur de paiement distant 
apte a crediter l'editeur. 

Dans cette variante, les moyens securises 

20 peuvent comprendre un lecteur de carte a puce avec une 
carte a puce contenant l'identite de 1 1 utilisateur, la 
carte etant apte a recevoir le deuxieme message, a 
controler la preuve qu'il contient, a enregistrer la 
demande de paiement et a constituer le troisieme 

2 5 message d 1 acquittement . 

Regulierement , 1' ensemble des demandes 
enregistrees dans la carte, qui correspondent a des 
usages de logiciels, sont rapatriees dans le serveur 
grace a un reseau de telecommunications, 

30 La carte peut etre du type prepayee (sous 

forme par exemple de porte monnaie electronique) ou 
postpayee . 
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Breve description des figures 

- la figure 1 illustre un systeme conforme a 
1' invention dans sa premiere variante ; 

5 - la figure 2 illustre un arbre de 

certification avec une chaine de certificats ; 

- la figure 3 illustre un systeme conforme a 
1* invention dans sa seconde variante. 

10 Description detaillee de modes particuliers de 
realisation 

On voit, sur la figure 1, un ordinateur 
personnel PC suppose contenir un logiciel L, dont on 
veut controler 1 1 utilisation . Ce logiciel est associe a 

15 une interface logicielle IL, appelee par la suite 
"MARCHAND" , qui communique avec le systeme de paiement 
proprement dit. On trouve egalement un module de 
paiement W, appele par la suite "WALLET". A distance se 
trouve un serveur de paiement SP, relie au module 

20 WALLET par une ligne de transmission (non representee) . 
L'editeur du logiciel est reference E. 

Dans la variante illustree sur la figure 1, 
lorsque le logiciel L a decide de demander un nouveau 
paiement, un message d 1 off re reference 1 est emis par 

25 1' interface MARCHAND a destination du module WALLET. Ce 
message d'offre peut contenir : 
o l'identite de l'editeur ; 

o la description de 1' off re, texte comprehensible par 
1 1 utilisateur explicitant ce qu ! il va obtenir 
30 moyennant paiement (par exemple : "30 minutes 
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supplementaires d 1 utilisation" ou bien "scene 3 : 
duree 25 minutes") ; 

• le prix (montant, unite monetaire, etc.) 

• l'heure et la date interne du PC ; 

• un alea interne ; 

• une signature par 1'editeur du logiciel de cette 
offre, sous la forme S E (offreh, prix) ou offre 
signifie "condense des donnees de 1 'offre". 

Le module WALLET recevant ce message va 
demander a 1 1 utilisateur U s'il est d' accord pour 
accepter cette offre. Par exemple, une fenetre est 
affichee a 1'ecran, visualisant la description de 
1 'offre, l'heure et la date, le montant et 1' unite 
monetaire a payer, et ce meme prix converti en Francs 
frangais. Cet affichage est symbolise par la fleche la 
sur la figure 1. 

Si 1 1 utilisateur U est d' accord, il clique par 
exemple sur une case " accord " (reponse symbolisee par 
la fleche lb sur la figure 1) . Le module WALLET emet 
alors le message 2 "demande de paiement" a destination 
du serveur SP. Ce message peut contenir : 

• un condense de l ! offre h/ . le prix, la date et 
l'heure, l'alea, la signature S E (offreh, prix) ; 

• l'identite de 1 ' utilisateur U, et celle de 1'editeur 
E ; 

• une preuve que le client est d' accord pour acheter 
cette offre. La nature de la preuve peut dependre du 
mode de realisation : ce peut etre un mot de passe 
envoye au serveur de paiement SP, ou un code 
confidentiel donne a une carte a puce, qui elle-meme 
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fournit au serveur SP une preuve cryptographique : 
signature, etc. . 

Le fait de transmettre un condense de 1' off re 
("offreh") et non 1' off re complete permet au client de 
5 ne pas reveler au serveur SP ce qu'il selectionne, sans 
empecher les controles par le serveur SP. 

Le serveur de paiement SP recevant cette 
demande de paiement 2 effectue alors les operations 
suivantes : 

10 o controle de la preuve donnee par le client, 

o conversion en Francs frangais, si necessaire, 
o controle de la consommation de 1 1 utilisateur ; & 
titre d'exemple, le serveur SP verifie que le cumul 
de ce qui a ete consomme depuis le debut de la 

15 periode est inferieur au montant d 1 autorisation 

attribue a cet utilisateur (cas du post-paiement ) , ou 
bien que ce cumul est inferieur a la provision 
constitute par 1 ' utilisateur a cet usage (cas du 
pre-paiement ) , 

20 © enregistrement de la demande de paiement, pour 
pouvoir realiser ulterieurement les operations de 
paiement ; cet enregistrement comporte au moins : 
-1 ' identification de 1 ' utilisateur, 
-1 1 identification de l'editeur du logiciel, 
25 -le prix, 

-l'heure et date, le condense offreh / 

o constitution du message 3 d 1 acquittement , qui va 
prouver au logiciel et a son interface "MARCHAND" que 
le paiement a bien ete realise ; ce message 
30 d 1 acquittement, pour etablir une preuve verifiable, 

contiendra : 
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— l'identite du serveur SP, 

-la signature S S p (offreh, prix, alea, date- 
heure) par le serveur de paiement, 
Le module WALLET transmet simplement le 
5 message regu a 1 1 interface MARCHAND. 

L 1 interface MARCHAND verifie la signature 
S S p (offreh/ prix, alea, date-heure) du message 
d' acquittement , par rapport aux parametres de l f offre 
precedemment envoyee. S'il y a concordance, alors 
10 1' execution du logiciel L peut continuer. 

Periodiquement , tous les mois par exemple, le 
serveur SP calcule le cumul des depenses engagees par 
chaque utilisateur, et il provoque, dans le cas d'un 
post-paiement , le paiement effectif des sommes dues au 
15 moyen d 1 une carte pour lequel la connaissance prealable 
du numero de carte du client est necessaire, ou par 
prelevement automatique sur le compte du client. 

Pour le pre-paiement , ceci se fait par le 
rechargement volontaire par 1 1 utilisateur de sa 
20 provision chez un intermediaire. 

De meme, le cumul par l'editeur permet de 
calculer le montant du a chaque editeur. 

Les traits pointilles du dessin de la figure 1 
correspondent a ce flux financier du serveur SP vers 
25 l 1 editeur. 

Pour 1 1 etablissement des differentes 
signatures mentionnees ci-dessus, on peut utiliser un 
systeme a cle publique avec arbre de certification. 
30 Cette solution est en effet l'une des rares qui 
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permettent de concevoir des systernes simples, surs, 
ouverts et internationalement reconnus. 

Les principes de cette technique sont bien 
connus. La mise en oeuvre est schematisee sur la figure 
5 2. Urie autorite A definit la "racine" de l'arbre de 
certification, dans lequel se trouvent les differents 
acteurs du systeme : 

- les editeurs de logiciels utilisant ce moyen 
de paiement, 

10 - les serveurs SP, 

— les entites intermediaires ; dans I'exemple 
de la figure 2, il pourrait s'agir d'un 
syndicat d' editeurs de logiciels d'un pays 
(SYND) , et d'une autorite nationale de 

15 regulation des serveurs INTERNET (SINT) . 

Ainsi, lorsqu'un logiciel de tel editeur de 
logiciel est utilise par un utilisateur correspondant a 
tel serveur SP, des certificats joints aux messages 2 
et 3 permettent de verifier les signatures. 

20 Pour le message d'offre (message 2) 1' editeur 

E peut adresser au serveur SP un message contenant le 
condense offre h , le prix, la date et l ! heure, l'alea, la 
signature S E (offre h , prix) , le certificat de E par SYND, 
le certificat de SYND par A. 

25 Le serveur SP, qui connait la cle publique de 

A, verifie le certificat de SYND par A, avec la cle 
publique de A. II obtient done la cle publique de SYND, 
de fagon sure et verifie le certificat de E par SYND 
avec la cle publique de SYND. II obtient aiors la cle 

30 publique de E, de fagon sure, et peut finalement 
controler la signature S E . 
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La variante qui vient d'etre decrite peut etre 
qualifiee de "en ligne" ("on line") car 1 1 utilisateur 
doit se connecter, par exemple par le reseau INTERNET, 
au serveur SP a chaque demande de paiement. Cette 
version n'est acceptable que pour des paiements peu 
frequents (par exemple pour pouvoir recevoir un film 
sur DVD-ROM qui dure 2 heures) . 

L 1 invention prevoit une autre variante, qui 
est mieux appropriee aux paiements repetes. Cette 
variante est decrite sur la figure 3. Elle suppose 
1 'existence d'un lecteur de carte LC et d'une carte C. 
Comme la carte constitue un support sur, elle remplace 
le serveur SP en ce qui concerne les messages 2 et 3, 
lesquels circulent alors entre le module W et le 
lecteur de carte LC. Cette variante peut etre qualifiee 
de "off line" (hors connexion) par opposition a la 
premiere. Le paiement de l'editeur E s'effectue 
tou jours par le serveur de paiement SP, lequel regoit 
periodiquement les informations memorisees dans la 
carte (ligne PP) . 

S'agissant de la carte C, on peut distinguer 
deux cas : 

• la carte est une carte pre-payee (du type carte 
porte-monnaie electronique, par exemple) ; la 
provision financiere diminue a chaque fois qu ! un 
message de demande de paiement est traite ; alors, il 
n'y a pas de risque d'impayes, car la carte avant de 
se vider, a du etre chargee ; il faut cependant 
relever les utilisations qui ont ete fait.es, pour 
pouvoir payer les editeurs, selon 1 1 utilisation de 
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leurs jeux ; ceci peut par exemple etre fait au 
moment du rechargement de la carte ; 
o la carte est une carte post-payee : le risque existe 
que les utilisations enregistrees dans la carte ne 
5 reviennent jamais a 1 1 intermediaire, done que le 

client ne soit jamais debite, et par voie de 
consequence que les editeurs des logiciels utilises 
ne soient pas credites. La parade a ce probleme 
consiste a limiter les paiements a un certain plafond 
10 et/ou a faire payer une caution superieure a ce 

plafond, qui dissuade 1 1 utilisateur de faire 
disparaitre sa carte. 

Du point de vue des mecanismes precis, cette 
15 seconde variante reste tres proche de la premiere, si 
ce n'est le remplacement du serveur SP par la carte C. 
Cette carte devra done contenir un fichier des 
utilisations qui, comme dans le cas du serveur SP, 
contiendra les enregistrements des transactions, eux 
20 memes contenant au minimum les informations suivantes : 

- 1 1 identification de 1 1 utilisateur, 

- .1 1 identification de l'editeur du logiciel, 

- le prix. 

Si 1 1 on accepte de sacrifier un peu de 
25 securite pour ne pas avoir le surcout du lecteur de 
carte, la carte pourra etre remplacee par un moyen de 
memorisation integre au PC. 

Pour que le fichier des demandes de paiement 
ne soit pas trop facilement alterable ou effagable, il 
30 faut utiliser des techniques de fragmentation/ 
dissemination sur la totalite du disque, dont la 
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complexity constituera une barriere, certes moins forte 
que la securite physique des cartes a puce, mais 
suffisante dans bien des cas. 
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RE VEND I CAT IONS 

1. Systeme de paiement pour 1 f utilisation d'un 
logiciel (L) conteau sur un support, ce logiciel 
contenant une interface (IL) , le systeme comprenant un 
module de paiement (W) et des moyens de traitement de 
messages et de paiement (SP) , les fonctions de ces 
moyens etant les suivantes : 

o 1' interface logicielle (IL) est apte a constituer un 
premier message (1) qui est un message d'offre 
d 1 utilisation du logiciel, ce premier message (1) 
contenant, notamment, l'identite de l'editeur du 
logiciel (E), des parametres de l 1 off re, la signature 
numerique par l'editeur d ! au moins une partie de 
1' off re, ce premier message etant adresse au module 
de paiement ; 

o le module de paiement (W) est apte a recevoir ce 
premier message (1), a l'afficher (la), a recevoir en 
retour 1 1 acceptation eventuelle de 1 1 utilisateur (U) 
du logiciel (lb), et en cas d 1 acceptation, a 
constituer un deuxieme message (2) de demande de 
paiement contenant notamment l'identite de 
1 1 utilisateur (U) et celle de l'editeur (E) ainsi 
qu'une preuve que 1 1 utilisateur (U) accepte l'offre, 
ce module (W) etant apte a adresser ce deuxieme 
message (2) aux moyens de traitement (SP) ; 

o les moyens de traitement de messages et de paiement 
(SP) sont aptes a recevoir le deuxieme message (2) , a 
controler la preuve qu'il contient, a enregistrer la 
demande de paiement avec au moins l'identite de 
1 1 utilisateur (U) et l'identite de l'editeur du 
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logiciel (E) , le montant a payer et a crediter 
l'editeur (E) dudit montant, ces moyens etant aptes 
en outre a constituer un troisierne message (3) , qui 
est un message d 1 acquittement, ce troisierne message 
(3) comprenant, notamment, I'identite des moyens de 
traitement et une signature numerique qui constitue 
la preuve du paiement, ce troisierne message etant 
adresse au module de paiement W ; 

• le module de paiement (W) est en outre apte a 
retransmettre ce troisierne message (3) a 1' interface 
logicielle (IL) ; 

• 1 1 interface logicielle (IL) est en outre apte a 
verifier la signature des moyens de traitement par 
rapport aux parametres de 1* off re contenue dans le 
premier message et, en cas de concordance, a 
autoriser 1 1 utilisation du logiciel (L) . 

2. Systeme selon la revendication 1, dans 
lequel les moyens de traitement de messages et de 
paiement sont constitues par un serveur de paiement 
distant (SP) relie au module de paiement (W) par un 
reseau de telecommunications, ce serveur (SP) recevant 
et traitant le deuxieme message (2) et constituant et 
emettant le troisierne message (3) . 



3. Systeme selon la revendication 1, dans 
lequel les moyens de traitement de messages et de 
paiement comprennent des moyens securises (LC,C) 
contenant au moins I'identite de 1 1 utilisateur (U) , ces 
moyens etant aptes a recevoir le deuxieme message (2), 
a controler la preuve qu'il contient, a enregistrer ,1a 
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demande de paiement et a constituer le troisieme 
message d 1 acquittement (3) avec la preuve de paiement, 
et comprennent en outre un serveur de paiement distant 
(SP) apte a crediter 1'editeur (E) . 

4. Systeme selon la revendication 3, dans 
lequel les moyens securises comprennent un lecteur de 
carte (LC) avec une carte (C) contenant l'identite de 
1 'utilisateur, le lecteur de carte et la carte etant 
aptes a recevoir le deuxieme message (2) , a controler 
la preuve qu'il contient, a enregistrer la demande de 
paiement et a constituer le troisieme message 
d 1 acquittement (3) avec la preuve de paiement. 

5 . Systeme selon la revendication 4 , dans 
lequel la carte (C) est du type prepayee et contient 
une provision, la carte etant apte a debiter cette 
provision a chaque demande de paiement du montant de la 
demande. 

6 . Systeme selon la revendication 5, dans 
lequel la carte prepayee (C) formant le message 
d 1 acquittement contient une preuve que le montant de la 
demande du a ete debite dans la carte. 

7. Systeme selon la revendication 5, dans 
lequel la carte prepayee (C) est apte a constituer un 
fichier des demandes acquittees et des montants 
correspondants, le message d 1 acquittement n' etant emis 
avec sa signature qu 1 une fois la mise a jour de ce 
fichier effectuee . 



SP 16448 C/RS 



18 



8. Systeme selon la revendication 7, dans 
lequel la carte prepayee (C) peut etre rechargee, le 
fichier qu'elle contient etant transfere prealablement 
au serveur de paiement (SP) lors du rechargement . 

9. Systeme selon la revendication 5, dans 
lequel la carte prepayee (C) est du type porte-monnaie 
electronique . 

10. Systeme selon la revendication 4, dans 
lequel la carte (C) est du type post-payee. 
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